Kubernetes v1.31 - Elli

노트 속성
created 2024. 8. 15.
is-folder false
aliases 쿠버네티스 엘리
related 버전
index 1
webaddress https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/

개요

Kubernetes 1.31 버전이 나왔다는 사실을 뒤늦게 알게 됐다.
관련 문서들도 꽤 돼서, 변경점을 간략하게 정리해보고자 한다.

Elli

Pasted image 20240815204336.png
처음 알게 됐는데, 이 녀석들은 지네 릴리즈 버전마다 이름이랑 테마를 붙인다;;
정말 변태 같은 게 맘에 든다.

메인 문서도 존재하는데, 이거 정리는 조금만 미루고, 내가 처음 봤던 문서부터 정리한다.

캐시를 통한 일관된 읽기 작업으로 클러스터 성능 향상

쿠버네티스는 컨테이너화된 어플리케이션 환경을 견고하게 관리하지만, 클러스터가 성장하면서 컨트롤 플레인은 점차 병목현상을 겪는다.
핵심 과제는 리소스 집약적인 읽기 작업이 수행되는 Etcd 저장소에 대해 읽기 작업이 강하게 일관되도록 보장하는 것이다.
이에 대해 1.31 버전에서는 캐싱을 통해 일관된 읽기 작업 기능을 베타적으로 도입한다.

일관된 읽기 작업이 중요한 이유

쿠버네티스의 컴포넌트들이 최신 클러스터의 상태에 대해 정확한 인지를 하기 위해서는 일관된 읽기 작업이 보장되는 것이 중요하다.
이것이 보장되어야 컴포넌트들이 최신 정보를 기반으로 결정을 내릴 수 있으며, 쿠버네티스의 정확성과 신뢰성이 유지될 수 있는 것이다.
큰 규모의 클러스터에서는 데이터 처리와 불러오기 작업이 결과를 필터링하는 요청에 대해 특히 병목현상을 일으킬 수 있다.
쿠버네티스에서 데이터를 네임스페이스 단위로 etcd에서 선별하는 동안, 라벨이나 필드 셀렉터를 통한 필터링은 etcd에서 모두 불러온 후, api 서버에서 인메모리로 선별하게 된다.
이런 작업은 자신의 노드에 스케쥴된 파드의 리스트가 필요한 kubelet에게는 필요하지만 결국 api 서버나 etcd 입장에서는 클러스터 내부의 모든 파드들에 대해 처리해야 해서 작업이 과다하다.

해결법: 자신 있게 캐싱하기(with confidence)

쿠버네티스에서는 오랫동안 읽기 동작을 최적화하기위해 감시 캐시를 두었다.
감시 캐시는 클러스터 상태에 대한 스냅샷을 저장하고 etcd 감시를 통해 업데이트를 진행했다.
그러나 현재까지는 일관된 읽기 작업을 바로 수행할 수 없었기에 해당 캐시가 충분히 최신인지 보장되지 않았다.

캐시를 통한 일관된 읽기 작업은 etcd의 진행 알림 매커니즘으르 활용해 수행된다.
이 알림은 etcd와 비교했을 때 감시 캐시가 얼마나 최신인지에 대한 정보를 준다.
만약 일관된 읽기 작업이 요구된다면 시스템은 먼저 감시 캐시가 최신인지 확인한다.
만약 캐시가 최신이 아니라면, 시스템은 캐시가 충분히 최신임이 보장될 때까지 etcd에 진행 알림 질의를 날린다.
준비가 된다면 읽기 작업은 캐시를 통해 효과적으로 이뤄지며 이는 etcd에서 많은 데이터를 불러와야 하는 상황에서 특히 성능 향상에 유의미하다.
이렇게 캐시에서 데이터를 가져와 필터링을 하게 되고, etcd에서 읽어오는 것은 최소한의 메타데이터가 된다.

중요한 점
이 기능을 활용하기 위해서는 클러스터의 etcd 버전이 3.4.31이상이거나 3.5.13이상이어야 한다.
오래된 버전에서 쿠버네티스는 자동으로 etcd에서 읽기 작업을 수행한다.

성능 이점

쿠버네티스 성능과 확장성에 대해 생긴 단순한 변화

5천 개의 노드에서 확장성 테스트 결과

이후 과제

베타로 등급한 뒤 캐시를 통한 일관된 읽기 작업은 기본값이 된다.
감시 캐시는 현재도 개발 중이면서 이후에도 더욱 최적화될 것이다.

생각

그렇다는데, 코드로는 어떻게 구현됐을지 슬슬 궁금하다.
이를 위해 내가 알아야 할 것은 쿠버네티스 깃허브 디렉터리 구조와 고언어이다.
Rust를 먼저 배우고 싶었는데, 현재 목표 중 하나가 Kubestronaut이니 고를 먼저 배우는 것도 나쁘지는 않겠다.

참고